A brief overview of a prior art three tier management system is shown in FIG. 1. Here, a management server 10 communicates with management agent 12 resident on an endpoint computer workstation 14 (only one shown) via a gateway 16 (only one shown).
A well known example of such a system is Tivoli Software Distribution Version 3.6. Detailed information about the features offered by this product are available at in New Features in Tivoli Software Distribution from International Business Machines Corporation, Part #SG24-2045-0, ISBN 0738401099.
In a Tivoli system, each enabled endpoint 14 communicates with a gateway 16 via any peer-to-peer protocol, for exam TCP/IP, IPX or SNA. Communication between the server 10 and the gateway 16 is via an ORB (Object Request Broker) 18′,18″, connection where each endpoint connected to a gateway is addressed by the server through an associated object on the gateway ORB 18″, thus enabling the endpoint to be directly addressed by the server. A management agent 12 known as a Lightweight Client Framework (LCF), resident on the endpoint, is thus accessible by the server and enables the server to push software via the gateway to the endpoint and call methods on applications resident on the endpoint. The server in turn runs programs 20, 22, 24 allowing: software to be selected for distribution to specified endpoints or defined groups of endpoints; endpoint software inventories to be obtained; and endpoint activity to be monitored via an Event Console, and these programs are extended for each endpoint platform to be managed.
While this management system has been quite successful, it should be noted that in order to control any endpoint 14, the endpoint must itself be manually enabled by installing the LCF client 12 on the endpoint and configuring the LCF client accordingly, for example, setting up its gateway address and communication protocol.
At the same time more and more users are employing Tier 0 or pervasive devices (“devices”) 26 including, for example, Palm Computing® platform devices (“Palm devices”) from Palm Inc., a range of organizers from Psion plc and to a growing extent mobile and smart phones. Typically data on such pervasive devices 26 is managed locally by periodically connecting the pervasive device to a workstation 12 running a controller program 28 and synchronising one or more databases stored on the device, for example an address book, with corresponding databases stored on the workstation.
In the case of a Palm device, a workstation application called HotSync® Manager controls the synchronisation of databases as well as the installation of new applications. HotSync uses one or more plug-ins known as conduits, each for exchanging and synchronising data between the workstation 14 and the Palm device 26. Most conduits synchronise data such that data on the device mirrors the data on the workstation, although/others also transfer, import/export data, or cause Palm applications to be installed.
One of the default conduit modules (netcond.dll) responds to a user placing a Palm Network Configuration (.PNC) file in a pre-determined sub-directory prior to synchronisation. The file is copied to the device by the conduit module where it is used to update the script file for a modem. This, however, is extremely limited in terms of aspects of the device that may be configured. Also, the Palm desktop 28 includes a set-up menu, but this only enables a user to set workstation side modem and network parameters. If these are at odds with the Palm device, then errors can occur.
Because configuration facilities are so limited, perhaps because of the problems of trying to access databases on the pervasive device which might be in use and so locked or unavailable, thus causing such facilities to operate unreliably, new users of pervasive devices may end up spending more time than is necessary manually configuring the devices before using them profitably. Even the provision of a configuration program per se is not as helpful as it might be, because if it is to avoid the problem of accessing databases which might be locked during synchronisation, it needs to run separately to device synchronisation and thus places an extra burden on the user. This also make the management of such devices within a tiered structure more difficult.
If such pervasive devices are to be employed more efficiently within an enterprise, then they need to be quickly and easily configurable as well as capable of receiving and having enterprise applications and data updated as seamlessly as possible, preferably, within the same framework used to manage other resources within the enterprise.